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Editorial 



As an agency , we live today on yesterday *s 
discoveries . Today* s output, which pays the 

bills around here, is based largely upon 
technical breakthroughs made sometime in the 
past . Most of our people are working to pro- 
duce today *s results, but here and there, 
mostly in back rooms, there are a few scat- 
tered people doing the " discovery " work . We 
used to call them "break-in artists . ■ They are 
busy making tomorrow* s production possible 
and, in a very real sense, making it possible 
for tomorrow* s bills to be paid . 



Once in a while, one runs across d whole 
cluster of this discovery work . It is jas if a 
renaissance had broken out in one particular 
shop . A whole group of people seem to be bub- 
bling over with invention, intuition, anti 
di scovery. It is an exciting place to be, 

when it happens . 



For subscriptions =: 
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To submit articles or letters 
by mail, to: Pi, Cryptolog 

via PLATFORM mail, send to: 
cryptolg at barlc05 
(bar-one-c-zero-f ive) 
(note: no r O f in *log*) 



There used to be one or two managers who 
seemed to have such a renaissance around them 
wherever they went. They seemed to have the 
knack of creating an atmosphere that fostered 
discovery, that encouraged breakthroughs . 



I can remember studying those managers, to 
see if I could emulate their evident ability 
to stimulate the discovery process . I can 

remember going to management courses and read- 
ing various books on the latest fads in 
management styles , looking for clues about how 
to generate the atmosphere that discovery and 
creativity seem to need. / can't remember 
finding much that was useful ; it seemed to be 
easier to talk about things that were easier 
to count or measure . 



Contents of Cryptolog should not be repro- 
duced, or further disseminated outside the 
National Security Agency without the permis- 
sion of the Publisher . Inquiries regarding 
reproduction and dissemination should be 
directed to the Editor. 



For an outfit that depends so much on 
break-in artists, we ought to worry about 
finding, growing, and managing tomorrow's 
crop . Perhaps we already are. 
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he history of Russian military af- 

W fairs has been one of incompetence 
mixed with flashes of brilliance. 
The brilliance has usually been in 
the form of individual military 
"shakers and movers 11 who have risen to the oc- 
casion with determination and forcefulness to 
carry through their goals , come what may, to 
the end. One might include Marshals Suvorov 
and Zhukov or Admirals Senyavin and Gorshkov 
in this category. However, there is one indi- 
vidual , although he is little known in the 
West, who as a "shaker and mover" might be 
said to be the father of modern Russian naval 
intelligence: Admiral Adrian Ivanovich Nepe- 



Nepenin, in his capacity as Chief of the 
Baltic Fleet's Communications (and Intelli- 
gence) Service both prior to and during World 
War I, built the naval intelligence organiza- 
tion into a formidable arm of the Russian Navy 
and ultimately established roots which have 
carried over into the Soviet era. 



Adrian Ivanovich Nepenin was born 21 Oc- 
tober 1871 in Pskov Province, Russia. He en- 
tered the Russian Naval Academy in 1885 and 
graduated in 1889. In 1898 he was assigned to 
the Far East Fleet. In December 1904 Captain 
2nd Rank Nepenin was assigned to command the 
destroyer STOROZHEVOJ at Port Arthur. During 
the war with Japan, Nepenin was captured and 
spent the last part of that war as a POW in 
Japan. Between 1905 and 1910 Nepenin held 
various ship commands in the Baltic Fleet. 



Originally prepared as an Appendix to the 
author's article on "Communications Intel- 
ligence and Tsarist Russia , ” which ap- 
peared in the Jan 84 issue of Cryptolog . 



In 1910, after much thought, Nepenin sent a 
plan for reorganization of the Communications 
and Observation Service of the Baltic Fleet 
to Admiral Nikolaj Ottovich von Ehssen, 
Coinmander-in-Chief, Baltic Fleet. Admiral von 
Ehssen liked Nepenin 1 s energetic idea for the 
Communications Service and in 1911 appointed 
Nepenin as Chief of the Communications Ser- 
vice. Nepenin probably made Captain 1st Rank 
at this time. 



Over the next few years, under Nepenin* s 
guidance and direction, the Communicat ions 
Service — almost alone within the Russian Navy 
— achieved a high esprit de corps among all 
its personnel. By October 1915 Nepenin had 
achieved the rank of Rear Admiral for his ef- 
forts. His admirers included not only his own 
men but even foreign allies assigned to Russia 
during the war. During a visit to a Communi- 
cations Service airbase in the Baltic in 1916, 
Admiral Sir Richard Phillimore (British Naval 
Representative to Russian General Staff Head- 
quarters, "STAVKA," 1915-16) was quoted as 
telling the Communications Service officers 
and men: 
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"Everything is excellent in our Brit- 
ish Navy . . . except that we do not have 
such an Admiral as your Nepenin who 
knows everything."[l] 



On 6 September 1916, largely on the basis 
of his Communications Service record, Nepenin 
was offered and accepted the command of the 
Baltic Fleet along with the rank of Vice Ad- 
miral. Nepenin' s time as CINC, however, was 
brief with little opportunity to carry out his 
ideas on reorganizing and revitalizing the 
spirit of the Fleet. On 15 March 1917, while 
on his way to meet with a group of disgruntles 
sailors near the Helsingfors Railway Station, 
Nepenin was killed by a shot from behind by 
either a mutinous sailor (according to the So- 
viet version) or a German agent dressed in the 
uniform of a Baltic Fleet sailor (Russian 
emigr£ version). [2] 



Although Nepenin 1 s period on the stage of 
History was brief, he left an indelible im- 
print on the development of Russian naval in- 
telligence in the 20th century. 



FOOTNOTES 



1. Apparently Sir Richard forgot (?) in his 
remarks about Admiral Reginald "Blinker" 
Hall of "Room 40 OB" fame, 

2. Dudorov, Rear Admiral Boris Petrovich Du- 

dorov in the emigr£ journal Morskie Za- 
piski (The Naval Records), New York. See 
also The Russian Navy in War and Revolu- 
tion by G. K, Graf, Munich: R. Oldenburg, 
1923, pp. 119-121, and The Russians at 
Sea by David Woodward, London: William 

Kimber, 1965, pp. 181-182. For the trad- 
itional Soviet negative view of Nepenin 
from 1916 as "suppressor of the Revolu- 
tionary in the Baltic Fleet," see Pavlo- 
vich, N. B. (editor), Flot v Pervoj Miro- 
voj Vojne (The Navy in World War ITj 2 
vols, Moscow: Voenizdat, 1964, Vol 1, p. 
241. 
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When all good folks are sound asleep. 

And all the rest are counting sheep. 

He concentrates on cipher text. 

And contemplates ways mo9t complex 
To render an approved solution 
Of some obscure substitution. 

While all the world is sleeping, snoring 
Loud enough to rip the flooring. 

He derives much satisfaction 
From the spatial interaction 
Of poly-graphic frequencies 
And isomorphic sequences. 

Of characters on paper slips 
Better know as sliding strips. 

Slides them West and tries the "Chi" test. 
Slides them East and tries the "Phi" test, 
Clamps his pipe tight in his mouth. 

And grimly slides them North and South, 

And if success eludes him then. 

Tears them up and starts again. 

Meanwhile the clock ticks on and on. 

Until at long last comes the dawn. 

As the milkman rattles by. 

He is heard to heave a sigh. 

Slowly piles the work sheets higher, 

Calmly throws them on the fire. 

Having proved one simple fact; 

There can be do doubt of that — 

As suspected all along, 

Everything he did was wrong. 



from Signal Corps Bulletin No. 109, 
July-Dee ember 1940 
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e have seen and heard a lot lately 
about our writing. Our Director has 
made a special point of urging us to 
write more clearly and directly. A 
hard-hitting article on the same to- 
pic may be found in the November 1983 issue of 
CRYPTOLOG , pp. 13-18. A number of services 
are available to help us improve our communi- 
cation skills, including courses at the School 
and the new "Write-Line.'* The quality and ef- 
fectiveness of our writing and speaking is far 
more important than many of us seem to real- 
ize, in spite of these management initiatives. 
Unfortunately, our writing will only get 

better if we care about it and feel that it 
matters. I am not going to launch into a long 
article about good writing, or how to improve 
our writing. That has been done already by 
many others; I will mention two sources that I 
have found particularly useful. But I feel 
that good clear writing is an important human 
factors issue, and I'd like to say a few 
things about it in these Tech Notes. 



I read a lot of technical papers and 
research reports, and I edit my office's 
Monthly Research Summaries. I am sorry to say 
that I have seen a great deal of very bad 
writing. It is bad because it is not "user- 
friendly." I am going to direct my comments 
to anyone out there who writes the kinds of 
prose I have to fight my way through each 
month in our Research Summary. 



As a reader , I am a user of your paper or 
report, just like a user of any other tool. 
The paper probably says something I need to 
know or I wouldn't have picked it up. If you 
create long, intricate sentences choked with 
jargon, you are putting major obstacles in my 
way. You are making me spend far too much of 
my time and energy to get your meaning. Some- 
t imes your sentences are so complicated that 
you lose your own way through them, so how can 
you expect me, the reader, to understand them? 
I know that you don't set out to mystify the 
reader on purpose. I believe that scientific 
and technical writers have certain basic 
misconceptions about writing; some or all of 
these they probably learn from their teachers 
at colleges and technical schools, many of 
whom are also apallingly bad writers. Let's 
take a look at some of the faulty assumptions 
that may give rise to the bad writing techni- 
cal people so often produce. 



"If I say it simply, people will think 
I'm uneducated." 



People in technical fields have gotten so 
used to a certain very heavy, convoluted style 
of writing that simpler writing just sounds 
inappropriate and anticlimactic to them. Even 
if they are just telling us that they debugged 
a program or checked out some minor electronic 
gadget, they feel they must sound like a can- 
didate for the Nobel prize. 
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"If I say it simply, people won't know 
it's important." 



Many people seem to think that the length 
of their words and the complexity of their 
sentences are a direct measure of the impor- 
tance of the topic. I "use" a Kleenex to blow 
my nose, but I "utilize" the computer, because 
the computer is a lot more expensive and im- 
portant than a Kleenex or my nose! I might 
"make it easier" for the cat to use the litter 
box, but I feel I must "facilitate user acces- 
sibility" to project X. 



"If I say it simply, I won't be able to 
hedge and fudge." 



Technical and scientific people are masters 
of the art of hedging their bets. To some ex- 
tent, this is necessary and justified; we have 
a professional obligation to specify the de- 
gree of significance of a result , the relia- 
bility of a statement, or the statistical con- 
text of an event. We have to convey these 
matters to our readers at those times and 
places where they are important and appropri- 
ate. Unfortunately, the hedging gets to be a 
habit, so that it infects all our writing, and 
shows up in lots of places where it serves no 
purpose. ,1 suspect that the long sentences 
starting out with endless strings of subordi- 
nate clauses arise in this hedging habit. 
Each subordinate clause is like a safe little 
fence to push the bald, direct subject and 



verb further away from the reader, until the 
meaning disappears in a comfortable mist. I 
have seen some cases where the subject and 
main verb never arrive at all. In many cases, 
the writer has forgotten whether the subject 
was singular or plural, or even what the sub- 
ject started out to be, by the time he gets to 
the main verb. It's a real help to the reader 
when you put the main subject and verb at or 
near the beginning of the sentence. Don't get 
into the habit of writing English as if it 
were German! 



A frequent error I see in technical writing 
is the "dangling participle." The long string 
of subordinate clauses at the beginning of the 
sentence often starts with a participial 
phrase that does not refer to the real subject 
of the sentence. Strunk and White (reference 
2 below) say, "A participial phrase at the be- 
ginning of a sentence must refer to the gram- 
matical subject." [p. 8] As the reference 
states , sentences violating this rule are 
often ludicrous, for example, "Being in a di- 
lapidated condition, I was able to buy the 
house very cheap." Even when they aren't rid- 
iculous , dangling participles are confusing 
and sloppy. This kind of writing doesn't im- 
press a careful reader with the quality of the 
writer' s thinking. 



"My readers are all experts in my field 
and know the jargon." 



Perhaps this is true; if so, I think the 
writer is making a mistake. What about 
managers in other organizations that might 
make use of his ideas? They may be familiar 
with the field at a global level without know- 
ing al 1 the buzzwords and abbreviations he 
tosses off in his report. What about techni- 
cal people in related fields? They may have a 
similar problem with some of the jargon. Fi- 
nally, I maintain that jargon and alphabet 
soup are far too often a lazy substitute for 
thinking. If we understand what we are doing, 
we should be able to express it clearly with a 
minimum of jargon. When I am talking to some- 
one who throws a lot of alphabet soup and jar- 
gon at me, I make a point of asking politely 
for one or two definitions or expansions. 
Very often, I get a blank look, a silence, 
then "Well, gosh, now that you ask, I don't 
know! " 
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"Oh, EVERYBODY knows what that means!" 



The remarks in paragraph 4 apply to this 
one too. I came across the phrase "reparti- 
tioning the functionality" in a recent 
research summary . I very much doubt that 
"everybody" knows what that might mean, and 
I'm sure that some simpler, clearer way could 
have been found to express the idea, whatever 
it was. 



"If I simply say 'somebody did thus and 
so,' I am leaving somebody's posterior 
alarmingly uncovered." 



We seem to think it is much safer for all 
concerned to use the passive voice. Nobody 
DID it. It just happened. It was done. That 
also sounds much more impressive, like an act 
of God: it rained, there was light. We've 
also had it hammered into us throughout a 
technical or scientific education that we must 
always be "objective." The worst sin in the 
world is to be "personal" or "subjective"! 
That 1 s another reason why we avoid the active 
voice like the plague and prefer passives or 
impersonal constructions like "there were in- 
dications that" and "it is apparent that." 
These constructions make our sentences need- 
lessly complicated right at the start: harder 
for us to write, and harder for the reader to 
read. At their worst, they can totally ob- 
scure the meaning. 



Here's a sample of user-unfriendly prose to 
illustrate the needless syntactic tangles and 
sloppy semantics of bad writing: "In addition 
to examining the use of, and designing a 
gadget for a fratnmus for project GLITCH, the 
use of a widget for project FOO was also stu- 
died." Exercise: find the subject of this 
sentence . Here 1 s a better way of saying it : 
"We designed a gadget for a frammus for pro- 
ject GLITCH, and examined its use. We also 
studied the use of a widget for project FOO." 
I am still unhappy about the vagueness of 
"studying the use" of gadgets and widgets. 
Does the writer mean "try out the gadget to 
see how useful it is"? Or does he mean "ob- 
serve operators using the gadget and study how 
they use it"? Maybe he means "perform various 
experiments to see if there is any point in 
trying to use the gadget . ” When we look 
closely at this sentence, we see that it 
doesn't convey much meaning to the reader un- 
less he already knows all the intimate details 
of the projects and equipment . 



In closing, I'd like to stress one final 
point: writing matters. It matters HOW some- 
thing is expressed. Engineers and mathemati- 
cians know that the formal systems they use 
(mathematical and scientific notation, models, 
and methods) are powerful tools. Computer 
systems people hold up certain standards for 
writing good code and for the efficient, 
economical use of programming languages. 
Technical people respect those tools and ap- 
preciate the value of elegance and economy in 
their use. Natural language is another tool, 
just as powerful and deserving of respect. 
Unfortunately, too many technical and scien- 
tific workers tend to ignore or look down on 
natural language. They don't think of English 
as a tool that can and should be used with 
elegance and skill . Their mathematics may be 
beautiful, and their programs may be clear and 
economical, but if their writing is messy 
their minds are likely to be a bit messy too. 
The exercise of stating something clearly and 
directly in good plain English can often clear 
up the mess for the writer as well as his 
readers . 



References 

"Just Plain English," Department of English, 
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Introduction 

(U) A National Supercomputing Research 
Center is important to NSA because it will 
help us to solve many future supercomputing 
problems . The word "super computing" simply 
means the intelligent use of the mo9t powerful 
computational tools currently available. Such 
a center will probably solve these problems 
better than we have done before and in a way 
to help other national defense efforts as 
well. It will do this with outside people and 
outside money. But we need to fight for it. 



Background 



(U) The Chief Scientist of NSA, Mr. Kermith 
Speierman, was asked by DIRNSA to formulate 
NSA recommendations for DoD regarding super- 
computer initiatives. The Speierman Committee 
was formed to develop those recommendations 
and reported to the Director in the autumn of 
1983, urging four functions for a federal 
supercomput ing initiative to help supercomput- 
ing: 



a. In-house , NSA : Highly classified special 
projects ; 

b. Defense Parallel Processing Laboratory 

( DPPL ) : Medium-level classified work on 

massively parallel processing for na- 
tional security in the next decade; 

c . NSRC : A largely unclassified lab for su- 
percomputing hardware and software 
research , with special emphasis on sup- 
port of : 

_d. Regional Computational Facilities (RCFs): 
An unclassified program to provide super- 
computer access to academic researchers. 

(U) The in-house function is already being 
performed and will continue. If no other ini- 
tiatives are acted on, RCFs will be partially 
done by the National Science Foundation (NSF) 
and the Department of Energy (DoE) labora- 
tories under existing plans . The really new 
features are the DPPL and NSRC. But the DPPL 
seems to be on its way to receiving accep- 
tance. Therefore, this article is dedicated 
solely to justifying the NSRC. 
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Possible Objections to the NSRC 



(U) The major objections to a new* indepen- 
dent NSRC are four: 



The vendors typically supply poor operating 
systems and FORTRAN . After all , operational 
software is not their main interest and some- 
thing really sophisticated is quite beyond 
their current capability. The result is that 
the users either get substandard performance 
from their machines or have to develop new 
opera t ing systems and languages , usually dif- 
ferent from anybody else's. 



(U) The DoE labs have developed their own 
operating systems with a line editor and com- 
plicated user commands that would be unsuit- 
able for NSA. T he NSA supercomputing 

environment — i.e., the l I svstem and IMP 

language — is powerful and easy fo use. Yet it 
cannot be the general super computing standard 
for various technical reasons; In addition, 
it is dif f icul t to trans fer to different 
machines. If we soon have a wide variety of 
supercompute rs, it wil l be impossible for us 
to maintain I I lMP on / all without a 

great increase in the number of systems pro- 
grammers. UNIX/C may become the de_ facto 

standard since it will boon i be available on 
almost all supercomputers . However, we see it 



as having inherent inefficiencies that make it 
difficult to use the full power of the com- 
puter when we wish to. D T 



1. No need because of current open research; 

2. The DoE labs could do this (and they want 
to) ; 

3 . An intense , open research program would 
transfer information and technology to 
the outer world; and 

4. Suggestions for an NSRC would arouse op- 
position from DoE or the President's Of- 
fice of Science and Technology Policy 
(OSTP) and thus possibly imperil the 
whole initiative. 



(U) I believe that objections 1 and 2 are 
essentially false (as stated) and that 3 and 4 
are true but can still be handled. 



Objection 1 



(U) One possible response is to put this 
problem in the DPPL or keep it in NSA (by us- 
ing more people). But the systems programming 
problem is essentially unclassified . How much 
better to free up NSAers and DPPLers for clas- 
sified work and put systems software in the 
NSRC, where it will be serving an independent 
need anyway (support of the regional centers). 
Driven by a variety of applications from 
academia, with a few clever interns from the 
labs and NSA bringing the best of their 
methods, the NSRC could have a resounding suc- 
cess. Specifically, they might well develop 
once and for all a portable , easy, powerful 
environment that could be used by all and 
enhance the vendors' products at the same 
time. And the really great thing is the lev- 
erage we get by having this work done by other 
people with others' money. Similar statements 
could surely be made in the other areas of 
NSRC emphasis besides languages and operating 
systems ; i.e. , algorithms, hardware technol- 
ogy , architecture, numerical analysis, artifi- 
cial intelligence, and graphics. 



(U) This objection is that no radically new 
efforts in unclassified supercomputing 
research are necessary because of existing 
work in government, industry, and academia. 
However , a look at specific examples (e.g. , 
operating systems and software) shows how 
inadequate the current efforts really are. 
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Objection 2 

(U) Los Alamos National Labs would dearly 
love to have the functions of the NSRC. How- 
ever, even a casual glance at their record 
must produce skepticism inasmuch as: 

[] they get relatively poor performance from 
their Crays (the current standard super- 
computers) ; 

[] they have a clumsy operating system; 

[] they discourage assembly language and 
modern high-level languages; and 

[] they have relatively few experts, partly 
because they have not encouraged (as NSA 
has) scientific personnel to become rela- 
tively sophisticated. 

(U) Maybe they will change if the labels on 
their doors are changed, but I doubt it. And 
I doubt that even "safeguards" written into 
new terms of reference, or even a change of 
location, would really change their modus 
operand i . If Los Alamos gets the NSRC, then I 
predict that the whole effort will be ir- 
relevant to NSA and we will be back to having 
to use many NSAers and DPPLers to do unclassi- 
fied work. 




Objection 3 

(U) The Speierman federal initiative would 
result in some information transfer to the 
outside. However, since the outside world is 
no longer very far behind us, the real ques- 
tion is what will be the marginal increase in 
harm (as opposed to what would happen anyway), 
weighed against the potential benefits to us. 
Since the in-house programming and the DPPL 
are classified, the only threat comes from the 
regional centers and the NSRC. The regional 
centers should provide only computational ac- 
cess at the end of a telephone line, and that 
only by grant. Thus the foreign graduate stu- 
dent in astrophysics could get time to study 
galactic structure, but he could not dump 
critical software, and he would have to break 
the terms of his grant to study cryptography 
on the sly. The NSRC itself should be physi- 
cally restricted to US nationals since it will 
have at least company proprietary, and possi- 
bly classified, information. The problem with 
the NSRC is that useful hardware and software 
work will eventually become public. After 
all, the people there will be developing very 
powerful unclassified operating systems. My 
contention is that the outside world is catch- 
ing up anyway. It is far better to have them 
trying to get up to the level of our unclassi- 
fied base a few years after us than for us to 
have an unclassified base behind that of other 
countries and to try to build our classified 
technology from it. 



Objection 4 

(U) If the NSRC is worth having, it's worth 
fighting for . We should not regard it as a 
political chip to be bargained away for DoE 
support for the whole initiative. The best 
approach is to keep trying to persuade the in- 
terested part ies , especially DoE , that the 
NSRC is in their best interest too. They also 
will get leverage from having the NSRC solve 
their problems. 
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Y ou may not have noticed , but the 
time function on our UNIX systems 
has been converted to GMT, or ZULU 
time- The other day, the phone rang 
and the voice at the other end said , 
"The boss would like to see you at 2 :45 to- 
day." Since 1 was on the system and probably 
would be for most of the day, I typed in 

remind 2 :30 
See boss at 2 :45 

and finished with a control-D. Then, being a 
cautious sort (remind has sometimes had a mind 
of its own) , I typed in 'delrem' and looked at 
what the system thought it was going to do. 
By now you have guessed that the system, 
operating in the time zone of the mythical 
kingdom of ZULU, had stored away my **wake up 
call 11 as 1430Z. So much for modern effi- 
ciency. 

Now 1 don't really mind using ZULU time, 
but it's just three more things to remember: 
the summer difference, the winter difference, 
and which are we in right now. Frankly, I'm 
still trying to remember all my PIN numbers 
(how many bank cards do you have?), and all 
the passwords to the various systems , and a 
couple of door combinations, and... well you 
get the idea. Every time I get another one of 
these important things to remember, I forget 
something trivial like a birthday or an an- 
niversary. 

So I went looking for some, way to get the 
system to keep track for me. What I found 
were two shells, one short and sweet, and the 
other much more involved • Here is the first 
one, called "tyrne" : 



date "+%H 11 | » t 
expr $t - 05 | » t 

date "+TIME : ZULU ($t :%M ESI)" 

What 1 hadn't realized was how much the 
'date' program had changed since UNIX Version 
6. Since Daylight Saving Time runs from the 
last Sunday of April to the last Sunday of Oc- 
tober, 1 added some commands and the shell now 
looks like this : 

date "+%m" | = a 
date ,, +%d" | = b 
date "+%w" | = c 
expr $b - $c | - d 
switch "$a" 

: 'standard time' 



= e S 
- f 05 
breaksw 

'last Sunday in April change' 

if $d -ge 24 then 
« e D 
- f 04 
breaksw 

else 

* e S 

* f 05 
breaksw 

end if 

'daylight saving time' 
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: 09 

= e D 
= f 04 
breaksw 

; 'last Sunday in October change' 

: 10 

if $d -ge 25 then 
= e S 
= f 05 
breaksw 

else 

= e D 
= f 04 
breaksw 

end if 

endsw 

date "+%H" | = t 
expr $t - $f | = t 

date "+T1ME: %H:%M:%S ZULU ($t :%M E$eT) n 



At the other end of the scale. I fo und the 
shell 'timel', written by | [ in P14. 

It begins in the following column. 

P . L . 86-36 

The original version of Bob's shell uses 
reverse video to set up a rather startling 
display on the screen. It will also clobber 
your terminal if you try to use it across the 
network. If you get the original version, you 
could insert a test to see whether the termi- 
nal of the user was a network terminal, some- 
thing like : 

switch "$t" 

: [X-Z] 

(change to net-friendly version •••) 



endsw 

depending upon how the network terminals are 
labelled on your host. Then all you need is a 
second version of those lines that have re- 
verse video, replacing them with whatever your 
artistic heart desires. 



After some discussion, we decided to print 
the shell without the inverse video, in the 
interests of minimizing the chaos around the 
TSS community. 




goto start 

; Bob Jones, P14, 3369-s 
: (574 I-s) — 04 Mar 83 
: See list of variables at end of file 
: start 

date "+%H" | = t 

date M +%d n | = d 

date "+%j" j = c 

expr $t - 5 | = 1 

expr $t + 3 j = m 

expr $t + 09 | = k 

expr $t + 11 | * f 

if $k -gt 23 then 
expr $k - 24 [ - k 

expr $d + 01 | * a 

expr $c + 1 | = b 
else 

expr $d + 0 | = a 

expr $c + 0 | = b 

end if 

if $f -gt 23 then 
expr $f - 24 | = f 

expr $d + 01 | = g 

expr $c + 1 | = h 
goto skip 
else 

expr $c + 0 | * h 

- g "$d" 

expr $g + 0 | = g 
end if 
: skip 

if "$g" -it ”10" then 

- g "0$g" 

else 
end if 

if "$d" -It n 10 n then 

- d "0$d" 
else 

end if 

if "$h n -It "100" then 
= h n 0$h" 
else 
end if 

if "$b n -It "100" then 
= b "0$b" 
else 
end if 

if "$f" -It "10 M then 
= f "0$f" 
else 
end if 

if "$k" -It "10" then 

- k "0$k" 
else 

end if 

if "$a" -It "10" then 

- a "0$a" 
else 

end if 

if "$1" -It "10" then 
= 1 " 0 $ 1 " 
else 
end if 

if "$m" -It "10" then 
= m "0$m" 
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date 

echo 


"+** 

»** 


LOCAL 


DATE: 


%d 


%h % y 


TIME: 


§1 :ZM 


(EST) 


JULIAN 


DATE: 


%y%3 


**» 

**» 


date 

echo 


"+** 
11 ** 


ZULU 


DATE: 


%d 


%h 


%y 


TIME: 


St :%M 


(Z) 


JULIAN 


DATE: 


%y%j 


**» 

**» 


date 

echo 


»+** 

»** 


MOSCOW— 


DATE : 


%d 


%h 


Zy 


TIME: 


$m:%M 


(C) 


JULIAN 


DATE : 




**» 

**" 


date 

echo 


"+** 

"** 


KOREA 


DATE: 


$a 


%h 


%y 


TIME : 


$k. :%M 


(I) 


JULIAN 


DATE: 


%y$b 


**" 

**» 


date 

echo 


"+** 

»** 


FIJI 


DATE: 


$g %h 


%y 


TIME : 


$f :%M 


(L) 


JULIAN 


DATE: 


%y$h 


**" 

**" 



pump 

** ** 
********************************************************************** 
********************************************************************** 




~G 

I 

exit 

: 'VARIABLES-(refered to as $t, $m, etc) — t or $t= s system hour; d or $d a! system ' 
: 'date; c=system Julian Day; l=local time; m=Moscow time; k=Korean time; ' 

; 'f=Fiji Time; The following are computed if the time is after 2400 — ' 

: 'a=Korean Date; b=Korean J=Day; g*=Fiji Day; and h*=Fiji J^day. ' 

: 'Other computations such as 'if $m -It 11 10" then' place a zero in front of 
: ' '$m'. This, and the statements such as 'if n $h" -It "100" then' are 
: 'required because the math functions will drop leading zeros* 

: ' ~G — Rings Terminal Bell' 



Bob also has a version of this that runs on 
the IBM PC in living color. I'm sure he would 
be happy to let you have a copy of either ver- 
sion. 



These shells are more for demonstration 
than anything else, and that is the spirit in 
which they are presented here. For example, 
the first shell does not add a leading zero 
when the local hour is less than ten, and will 



probably do something weird if the local hour 
is less than 5. The third shell doesn't quite 
understand what to do at the end of the month 
and the 31st day in the land of ZULU may be- 
come the 32nd in some other time zone. If 
some reader comes up with a good fix, we will 
be happy to print it. 
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E.L. 86-36 

5J#A-fflr0jstir#53 



In case you were born 
on February 29th — 
Leap Year Day — well 
then. Happy Birthday 
to you , too ! 
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BE PART OF THE PROCESS ing 

CRYPTO-LINGUISTIC ASSOCIATION 
A LANGUAGE AUTOMATION 
/K COMMITTEE 

presents 




Translator/Transcriber Work Station 



Are you now using computer power in your language activities? 

Will you be using it soon? 

Feeling frustrated, intimidated, or uninformed about language automation 
in your office? 

At the TWS Work Shop you can 

* learn about current and future computer systems 

* express your ideas 

* share your concerns 

4-7 June 1984 
2W087 

Monday, Tuesday, Wednesday 0830-1100 

repeated at 1300-1530 * 

Thursday Wrap-up 1300-1500 

‘*v 



All interested Green-Badge personnel invited 



See you there! 
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AUTOMATED 
INFORMATION 
SECURITY: 



[uj 



£ ® E0 EIM T. STEEBLE,ca 



rP.L. 86-36 



I. Computer Security Guidance 

A. Policy Requirements 

omputer security requirements derive 
from the need for the information 
processing system to control access 
to classified information. These re- 
quirements are described more fully in the DoD 
CSC Trusted Computer System Evaluation Cri- 
teria , 15 August 1983 [ 1 ] . Briefly, such sys- 
tems are required to implement the following: 




[] MARKING - An ADP system which is used to 
process or handle classified or other 
definitely categorized sensitive informa- 
tion shall clearly store and maintain the 
integrity of classif ication or other sen- 
sitivity marking labels for all informa- 
tion. The system shall assure that the 
classified or other sensitive information 
is accurately marked when included in 
output from the ADP system. 



This article is extracted from the 
Department of Defense Computer Security 
Center's (DoD CSC ) response to the USMC. 
The Marines had requested computer securi- 
ty guidance and evaluations of several 
architectu ral plans . That pape r was au- 
thored by | | Chief of 

the Applications E valuations Systems Of- 
fice, with aid from \ H \ chi e f 

Sci entist ■ DoD C omputer Security Center 
and 1 | Col , USAF, Deputy Direc- 

tor, DoD Computer Security Center. The 
COMSEC policy, p rocedures , and gu idance 
were supplied by | | COMSEC 

Doctrine and Threa t Assessment Office; 

I 1 CQMSEC Standards and 

Evaluations Office; and | i | 

Jr., COMSEC Applications Office . 



For this publication minor editing and 
revisions, mostl y to delete USMC I specif- 
j'cs, were done by | | Chief, 

Operational Systems Evaluation Division, 
DoD Computer Security Center. 



[] MANDATORY SECURITY - The computer system 
must enforce the formal system of infor- 
mation control reflected in the security 
^classification designation and special 
handling restriction set associated with 
the sensitive information handled or pro- 
cessed by the ADP system together with 
the clearance set associated with the 
individuals who may request access to the 
information. 

[] DISCRETIONARY SECURITY - The computer 
system must enforce access limitations 
placed on classified or other sensitive 
information based on identified individu- 
als or groups of individuals who have 



been determined to have a Need-to-Know 
for the information. 

[] ACCOUNTABILITY - An ADP system which is 

used to process or handle classified in- 
formation must account for usage on a 
named-individual basis whenever classi- 
fied information is generated or ac- 
cessed . 

[] CONTINUOUS PROTECTION - Security-relevant 

portions of a trusted computer system 
must be maintained under configuration 
control to assure that unauthorized 
changes have not been made which could 
possibly subvert the. system's ability to 
control classified information. 
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These policy requirements form the basis for 
defining security requirements at the system 
level, as well as for the hardware and 
software components of the system. They also 
determine procedural requirements to support 
the continuous protection p'olicy and assure 
the operational effectiveness of technical 
safeguards . 

The degree to which a system must comply 
with these requirements, either in the use of 
specific security features or in the degree of 
assurance that the features are effective, is 
a function of risk of exploitation. This risk 
depends upon motivat ion , capability , and op- 
portunity of an opponent to exploit the 
system's protection controls and mechanisms. 
These factors, in turn, are influenced by such 
things as the most sensitive information in 
the system, the least restrictive clearance of 
system users or those associated with its 
development and operation, the hostility of 
the environment, and time. 



B. System Requirements 

A primary system requirement is to have a 
clearly defined security perimeter that in- 
cludes a suitable combination of manual and 
automatic trusted processes to control access 
to classified or sensitive data in the system. 
Each such process is designed and operated to 
implement a well-defined interpretation of DoD 
security policy (e.g., minimally, information 
that is labeled SECRET will not be accessible 
by personnel holding less than a SECRET clear- 
ance). The perimeter may be entirely defined 
by environmental ( i .e . , physical , personnel , 
and operational security) controls , as is the 
case in a dedicated mode of operation. It may 
require hardware, software, and COMSEC con- 
trols in addition to the environmental con- 
trols. For example, electrically connecting 
two different computer systems requires 
hardware and software controls over the inter- 
faces between systems operating at different 
system-high levels. These controls must en- 
sure, for example, that the , integrity of clas- 
sification labels on internal files is pro- 
tected and that information flowing from one 
system to another is classified no higher than 
the maximum authorized for the receiving sys- 
tem. This, in turn, requires assurance that 
the integrity of classification labels on 
internal files is protected in the computers , 
In the multilevel mode one relies very heavily 
on controls internal to the computer to en- 
force applicable security policy, and thus the 
computer hardware and software controls become 
an even more critical element of the security 
perimeter. 



The specific security requirements, both 
technical and environmental, to be enforced by 
a computer systems application are prescribed 
by the Designated Approving Authority (DAA) , 
in accordance with DoD Directive 5200 . 28 or 
DCI Computer Security Directive "Security of 
Intelligence Information in Automated Systems 
and Networks" (formerly DCID 1/16), while the 
requirements for determining the technical ef- 
ficacy of the system 1 s security controls and 
mechanisms are stated in the Center's Trusted 
Computer Systems Evaluation Criteria . The DAA 
is then required to make an explicit decision 
to use the system operationally when convinced 
that these security requirements are satisfac- 
torily met. We elaborate below on the com- 
puter hardware/ so ft ware certification and ac- 
creditation process to support this. 



C. Hardware Requirements 

Computer systems that are trusted to en- 
force a security policy employ a combination 
of hardware and software mechanisms. The 
hardware mechanisms of concern are those that 
simplify and optimize the implementation of 
access control over the subjects and objects 
as defined in the formal security policy model 
abstraction. Below we list desirable features 
worth considering in the selection of a 
hardware architecture. Note that these 
features , while helpful, do not supplant the 
need for a security kernel. However, they may 
improve performance throughput significantly 
over the pure use of software controls. 

[] Virtual Memory - This hardware feature is 
essential. It can be realized in either 
a page- or a segmented-based organization 
and would provide an effective environ- 
ment for multiple processes. Both re- 
quire address mapping circuitry that au- 
tomatically provides access checking dur- 
ing address translation. 

[] Execution Domain - It is minimally essen- 
tial that the hardware support two execu- 
tion domains (preferably three), where 
one domain is privileged and protected 
from the less privileged domain. Secu- 
rity kernel software runs within the most 
privileged domain, and untrusted user 
software executes within the less 
privileged domain(s). 

[] Controlled Access to I/O Devices - It is 
essential that computer architecture pro- 
vide some mechanism that enables a secu- 
rity kernel to maintain control over 
accesses to input/output (I/O) devices. 
A sufficient solution is the notion of 
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privileged I/O operations. Here, I/O is 
performed only by a process executing in 
the appropriate privileged domain. The 
kernel must control access to this 
privileged state . 

[] Multiple Processes - Many users normally 
share concurrently the available 
resources of a general-purpose computer 
system, therefore the base computer ar- 
chitecture must provide support for an 
efficient multiple— process structure. 
The minimal hardware support necessary is 
the capability to save and restore pro- 
cess definition information. 

Additional information may be found in MITRE 
Technical Report No. ESD-TR-78-170 "Minicom- 
puter Architectures For Effective Security 
Kernel Implementations" by John D. Tangney , 
dated October 1978. 



Because of the reliance one has on these 
controls , there are several security concerns 
to be addressed in the acquisition and use of 
this hardware . One concern is correctness . 
Assurances must be given to show that the 
hardware mechanisms have been designed and 
built to function correctly. A second concern 
is rel iabil ity . Failures in the hardware must 
not weaken or eliminate the security controls 
that are implemented in the hardware itself or 
in the software which , in turn , requires 
correctly functioning hardware. A third con- 
cern is integrity . Configuration control 
measures during hardware design, implementa- 
tion, operation, and maintenance must deter 
accidental or deliberate modifications of the 
hardware that can cause security controls to 
be bypassed or weakened. The degree of con- 
cern in each area and the corresponding steps 



taken to reduce the risk is application- 
dependent . Although exploiting such avenues 
of vulnerability is possible, one must con- 
sider them in the context of other areas which 
could be more susceptible to attack (e.g., 
software) . 



In those cases where the hardware will be 
used in a periods processing mode, it should 
permit rapid and reliable erasure of all 
internal memory (e.g., primary storage, non- 
removable secondary storage and buffers). It 
must also support the capability for a physi- 
cal disconnect from those other devices in 
areas with a lesser degree of protection. 
There is ongoing research as part of the con- 
solidated DoD Computer Security R&D program to 
develop a "job stream separator" which au- 
tomatically and reliably performs all neces- 
sary color change procedures. 

In those cases where the computer will 
simultaneously process or store information of 
different classifications, the hardware should 
support internal labeling of files with the 
appropriate security classification, and these 
internal labels should be used as the primary 
basis for access control decisions. This is 
particularly the case if the system users are 
not al 1 authorized access to all of these 
files (e.g., a9 in the controlled or mul- 
tilevel mode of operation). A similar re- 
quirement may exist for systems which process 
personnel proprietary or other sensitive un- 
classified information. 



Individual hardware components must meet 
TEMPEST requirements commensurate with their 
operational environment, current policy, and 
the perceived threat of exploitation. 
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D. Software Requirements 



E . Procedures 



Software that must enforce DoD security 
policy must be designed, implemented, and do- 
cumented to permit credible evaluation and ve- 
rification that it, in fact, correctly en- 
forces that policy. This requirement would 
have to be applied to all system software in- 
cluding the operating system, system utili- 
ties, data base management systems (DBMS), 
compilers, or application software. Such 
evaluation would be difficult and lack credi- 
bility if the security-relevant mechanisms are 
complex and scattered throughout the software. 
One simply cannot determine that an unstruc- 
tured collection of these mechanisms correctly 
implements the policy and cannot be circum- 
vented. Thus, the Center requires that in 
trusted computer systems all security-related 
functions be implemented in well-defined por- 
tions of software, firmware, and hardware, the 
totality of which is called the trusted com- 
puting base (TCB). The TCB must be designed 
and implemented so that its security controls 
are always invoked and are tamperproof, that 
is, the controls cannot be modified or 
bypassed by the remaining (untrusted) portions 
of the system and that they be of sufficiently 
simple design as to be subjected to thorough 
test and analysis . During its design and 
development , the TCB is subjected to specifi- 
cation and design analysis verification and 
testing to assure that these properties are 
indeed satisfied. The DoD CSC Trusted Com- 
puter System Evaluation Criteria amplify these 
requirements further. 



Determining the specific requirements for 
software controls and level of assurance, 
i.e., the evaluation class, for a particular 
application must reflect the level of risk and 
degree of trust required of the hardware and 
software. One indicator of this is security 
range that is, the difference between the 
classification of the most sensitive informa- 
tion and the least restrictive user clearance. 
Thus, for example, a Class C2 system may pro- 
vide adequate trust for a system-high applica- 
tion. A multilevel mode application would, on 
the other hand, normally be expected to meet 
the criteria of a Class B2 or higher system, 
depending on its security range. 




The continuous protection requirement is 
primarily satisfied with procedures to control 
and monitor access to hardware and software 
security components during their design and 
implementation, and then during their opera- 
tional life cycle. Such procedures are a 
critical part of gaining assurance that the 
security mechanisms are designed and built to 
meet stated requirements and then maintained 
and used to remain effective. Specific re- 
quirements include: 

[] clearing system support personnel to the 
highest level of data in the system; 

[] clearing maintenance personnel commen- 
surate with the sensitivity of informa- 
tion to which they could get access; and 

U developing and maintaining software which 
protects sensitive information in an en- 
vironment consistent with the sensitivity 
of the data being protected and with a 
level of risk that is acceptable to own- 
ers of sensitive information. 



In systems which involve periods process- 
ing, accreditable procedures are needed to 
change processing classification levels. Pro- 
cedures include removing sensitive data from 
the system, disconnecting or reconnecting 
peripheral devices and remote terminals , and 
rebooting the appropriate operating system at 
the new processing level. 



F. Classified Software 



The security mechanisms and their implemen- 
tation in trusted system hardware and software 
are generally unclassified. However, as noted 
earlier, this software may be treated as if it 
were classified to meet the continuous protec- 
tion requirement. There may be instances in 
which security-related software is classified 
(e.g. , if it implements a classified crypto- 
graphic algorithm) or security-related 
software contains classified data (e.g., the 
routing tables in a message system) . Such 
software must be protected like any other 
classified information while it is stored in L 

the computer. There may be multiple copies of 
it in primary and secondary storage, all of 
which must be labeled and protected, as must 
all hardcopy printouts of it. 
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G. General ADP Security Cert ificat ion/ Accreditation 

Planning Guide ( reference #2) prov ides add i- 
It is DoD policy that all ADP systems which tional information on the critical steps in 

process classified information will be ac- the certification/ accreditation process, 

credited; that is, there will be an explicit Further direct interaction with the user, 

decision that the system adequately protects designer, and C2 could follow the reading of 

information and can be used operationally. this literature and enable C2 to work on 

This accreditation is frequently based upon a recommending or finalizing a recommended 

technical evaluation of the system to deter- secure system, 

mine how well it meets predefined require- 
ments. However, unless the system is designed 
and built to be evaluated, as is NOT the case 
with most existing computer systems, the 
technical evaluation consists almost entirely 
of looking for flaws in the system or conduct- 
ing tests of the system's ability to withstand 

penetration. Neither case gives assurance II. Telecommunications 

that the system is secure because such exhaus- 
tive testing never finishes. Thus, it is vi- 
tally important that security requirements be A well-defined, layered network security 

identified early in the system's development. architecture is needed that 
It is equally important that the system secu- 
rity architecture identify trustworthy mechan- [] addresses all the threats of concern to 
isms to control the flow of information into, the user; and 

out of, and within the system. One can then 
determine explicitly the policy model which [ ] 

each trusted hardware and software component 
of this architecture must enforce and the ap- 
propriate Trust Class as described in the Cri- 
teria. One can then specify, implement, ver- 
ify, and certify that those enforcement It is desirable to have a single, layered, 

mechanisms that are implemented correctly en- inter-network security architecture that can 

force the policy. To assist with this, there be deployed across all DoD certified nets. An 

is a growing collection of formal design and ambitious DoD effort is under way to achieve 

verification methodologies which can be used. this initiative. 

These include SRI ' s Hierarchical Development 
Methodology, University of Texas 1 GYPSY sys- 
tem, and SDC's Formal Development Methodology. 

The C organization is undertaking an effort to III. Policy 

make these tools more easily available to and 
usable by system developers as well as by NSA 

and DoD system test and evaluation organiza- Electrical Interfaces - Electrical inter- 

tions . faces between systems operating at different 

classification levels must ensure that only 
appropriately classified information flows 
Computer vendors, (i.e., DEC, UNIVAC, from the more sensitive to the less sensitive 

Honeywell, etc.) have developed or are system. It must also prevent users of the 

developing trusted systems which might meet less sensitive system from making unauthorized 

long-range requirements. Additionally, changes, accidentally or deliberately, to data 

software houses are developing add-on packages in the other system or from disrupting its 

to provide a little increase in software secu- use. A manual interface has, until recently, 

rity (i.e., SKK* s ACF2 , IBM 1 s RACF, CGA 1 s Top been the accepted method. However, 

Secret , etc. ) . In Section III below we note trustworthy devices for controlling such in- 

other possible uses of trusted systems as part terfaces have been proposed for several sys- 

of the security architecture . Thus , a first terns . One such device currently in develop- 

step in developing the architectural strategy ment will use the Honeywell SCOMP as a basis 

and planning for using trusted systems would for implementing a GUARD to allow SECRET users 

be to determine what the long-term security to access SECRET data bases on the US Army 

requirements are (i.e. will multilevel secu- Forces Command's Top Secret system-high WWMCCS 

rity become an operational necessity, and if computer. There is another approach which 

so, over what range of classification and user uses a cryptographically derived cryptographic 

clearance?). check to verify the releasability of informa- 

tion when it is being electronically trans- 
ferred between security perimeters (reference 
#3). 



is consistent with, or is at least not 
incompatible with, the security architec- 
tures of networks to which various users 
are connecting. 
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*-Property[2] - DoD security policy for ADP 
systems was discussed in Section I above. The 
*-property is one part of the Bell & La Pa- 
dula[3] policy model for mandatory security. 
It is more conservative than DoD policy as it 
relates to paper documents but it precludes 
the success of Trojan Horse attacks. 



Data Aggregation - DoD policy for correct 
classification and handling labels for data 
elements (alone or in aggregate) should be im- 
plemented in data processing systems. This 
requires reliable labels on internal files and 
on output giving the classifications or other 
special handling instructions, as determined 
by the owner of the information at the field, 
record, file, or data base level, as appropri- 
ate. 



Data Encryption Standard (DES) - Present 
policy requires that NSA approve, on a case- 
by-case basis, any proposed use of DES to pro- 
tect classified communications. With respect 
to the use of DES to protect unclassif ied, na- 
tional security-related communications, re- 
cently issued national policy requires that 
Services, Departments, and Agencies determine 
the risk of exploitation of their unclassified 
communications, either in consultation with or 
based upon prior guidance from NSA in accor- 
dance with Federal Standard (FS) 1027. Where 
there is high risk of exploit at ion, NSA will 
prescribe or approve the cryptographic system 
used, on a case-by-case basis. For all other 
applications , commercial cryptographic systems 
(to include DES) may be used if they have been 
endorsed for general application by NSA. 




IV. General 



There will be additional costs associated 
with implementing, using, and maintaining phy- 
sical, emanations, personnel, and procedural 
security safeguards. Some of this additional 
cost (e.g., for physical and emanations safe- 
guards) is part of the capital investment. On 
the other hand, the costs for personnel and 
procedural safeguards are part of the opera- 
tional costs. The actual costs for a facility 
depend upon the level of protection required 
for the information being processed in a given 
threat environment. There will also be addi- 
tional costs associated with acquiring and us- 
ing trusted computer systems. Designing secu- 
rity into the system can lower these costs and 
have a beneficial payoff through improved re- 
liability and maintainability which results 
from a well-structured software design and im- 
plementation. We note that there are two key 
aspects to be considered in estimating the 
cost of safeguards in these security areas. 
They are (1) what level of protection is re- 
quired, and (2) how must these, safeguards be 
used and maintained to ensure their continued 
effectiveness? 
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Language 

Jun 83 Announcem ent : Two New Language Aids 
I land Chinese-Enelish) ; 

Jun 831 

I — r r , 

Aug 83 I Remember MabeT Babel I 
Latin American 

Apr 83 FBIS Latin American Reference Aid ; 

Linguists . 

Dec 83 Non Posse vs. Posse Non; 

H.G. 1 

Logic 

Jan 83 Logic D esign Exceed ing Boolean 
Capabilities ; | | 

EO 1.4. (c) 

P.L. 86-36 



EO 1 . 4 . (c) 
P.L. 86-36 



May 83 The Intelligence Watch Officer; T 

T P I I 



Mar 83f 



Pascal 

Jun 83 Why Pascal? (Why Not;?); T 

Password : / 

Mar 83 More on Passwords ; | 

May 83 Still More About Passwordsjf 
M.E. 



Performance 



fimeclock; 



Aug 83 Does Youf Office Make You Sick?; 



Personality j 

Mar 83 E.T. At NSA; 

Apr 83 Word People at NSA; -D ickson Airy* 
Aug 83 I Remember Mabel Babel j 
Nov 83 I Remember JFK; H.G. R 

Promotions I// 

Jun 83 Some Tips on Getting Promoted ; \ 

V. . 1 



P.L. 86-36 



Feb 84 * CRYPTOLOG * Page 28 



SECRET 




>OCID 




4009895 



Puzzle 

Jan 83 Puzzle; Williams D.H. 
Mar 83 Cryptic Crossword #3; Q 



SECRET 

/: #L" L. 8-6.-.S6 



I 



Dec 83 Letter to the Edit or: Tips o h Topical 
Reporting, Oct 83 Issue "1 
Dec 83 Letter to the Editor: Tips on Topica l 
Reporting, reply to Day's letter; | ~| 

D.G. E,O l 1 . 4 . (c) 

PXL. 86-36 

Satellites 

Apr 8 3 1 



Security 

Jun 83 Do You Know the Differences? ; f 
D.S. 

Jun 83 Letter to the Ed itor: Securi ty of 
Classified Information: ! \ 

Aug 83 Correction: Do You Know the 
Differences?, Jun-Jul 83 Issue; 



SIGINT 

Mar 83 SIGINT Challenge: A Scenario^ 
J.L. 



Sorting 

Jan 83 A Survey 
S.B. 



of Parallel Sorting; 

8 6-36 



ezi 



Soviet 

Apr 83 Government of the Pe ople, By The 
Party, For The Leadership; Q” 



Aug 83 Letter to the Ed itor: Govern ment of 



] 



the People... r eply to 



letter; 



Aug 83 Letter to the Editor: Government o f 
the People... > Apr 83 IsAue^ f I 

Oct 83 Soviet Military Goals And ThOi r Effect 
on Negotiations for Arras Limitations i 
G.L. 

Dec 83 Soviet Psi Experiments; 



Spanish 
Jun 83 T 

i =r 



Apr 83 NSA-Crostic No. 46; Williams D/H. 

May 83 NSA-Crostic No. 47; Williams D f H- 

May 83 Out of My Depth; 

Jun 83 NSA-Crostic No. 48; Filby V.R. 

Aug 83 Letter to the Edito r: Out of My Depth; 

May 83 Issue; I I 

Aug 83 NSA-Crostic NOi 49; Williams D.H. 

Sep 83 NSA-Crostic No. 50; Williams D.H. 

Nov 83 5-4-3 Puzzle; 'Watt Zizname r 
Dec 83 NSA-Crostic No. 51; Williams D.H; 

Dec 83 Out of My Depth; 



Reconna i s s anc e 

SeD 83 PARPRO: Reconnaissance Programs; 

I I / 

Reporting 

Aug 83 The Case of the 'Fowled-Up* CRITIC; 

I I . r 

Oct 83 Tips on Topical Report ing;|_ 



Dec 83 Non Posse vs. Posse Non; 
H,G. 



Staff 

Apr 83 My Staff — It Comforts Me; 1 Zebulon 
Zilch 

TDY 



Mar 83 TDY Travail; Filby V.R. 



TELECOM 

Oct 83 TELECOM 83: ; [~ 



Tempest 

Nov 83 Static Magic: The Wonderful World of 
Tempest; Donahue T.M. 

Nov 83 Tempest for Every Office; 



Terminology 

Sep 83 Do You Really Mean Julian?; 

C. 

Time 

Sep 83 Do You Really Mean Julian? 
C. 



Traffic Analysis 

May 83 Compute rizing Traffic Analysis; 

Nov 83 Letter to t he Editor: Computerizing of 
TA, May 83 Issue;] 



Training 

Mar 83 Announcement: Students! (NCEUR 
Independent Study Programs); 



UIS 



Apr 83 UI S: User Interfac e System Part One: 
Concept; I 1 

Apr 83 UIS: Us er Interfa ce System Part Two: 
Architecture; | | 



UNIX 

Mar 83 Shell Using If; H 



] 



Oct 83 Letter to the Editor: UNIX ED (I) 
Manual Page Comment ; | l 



Dec 83 Shell Game: System Shells; 
W.E . 

Video Teleconferencing 
Mar 83 Video Teleconferencing: NSA 
Appl ications ; Snodgrass C.L . 

Jun 83 Letter to the Editor: Video 
Teleconferencing, Mar 83 Issue;! 
J.R. W i 



Weather 

Mar 83 Weather : A Key Intelligence Indicator; 

P.L. 86-36 

Writing 

Nov 83 The Literary Bends; Murphy A. I. 

Nov 83 The White House Is Singing Our Song; 
Murphy A. I, 
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